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Preface 



Advances in networking technology have revitalized the investigation of agent 
technology as a promising paradigm for engineering complex distributed software 
systems. Agent technology has been applied to a wide range of application do- 
mains, including e-commerce, human-computer interfaces, telecommunications, 
and software assistants. Multi-agent systems (MASs) and their underlying the- 
ories provide a more natural support for ensuring important properties such 
as autonomy, mobility, environment heterogeneity, organization, openness, and 
intelligence. As a consequence, agent-based systems are likely to provide new ap- 
proaches to dealing with the complexity of developing and maintaining modern 
software. However, developing robust large-scale agent-based systems will re- 
quire new software engineering approaches. There are currently many methods 
and techniques for working with individual agents or with systems built using 
only a few agents. Unfortunately, agent-based software engineering is still in its 
infancy and existing software engineering approaches are unable to cope with 
large MASs. 

The complexity associated with a large MAS is considerable. When a huge 
number of agents interact over heterogeneous environments, various phenomena 
occur which are not as easy to capture as when only a few agents are working 
together. As the multiple software agents are highly collaborative and operate 
in networked environments, they have to be context-aware and deal with en- 
vironment uncertainty. This makes their coordination and management more 
difficult and increases the likelihood of exceptional situations, such as security 
holes, privacy violations, and unexpected global effects. Moreover, as users and 
software engineers delegate more autonomy to their MASs, and put more trust in 
their results, new concerns arise in real-life applications. However, many existing 
agent-oriented solutions are far from ideal; in practice, systems are often built in 
an ad hoc manner, are error-prone, not scalable, not dynamic, and not generally 
applicable to large-scale environments. Commercial success for MAS applica- 
tions will require scalable solutions based on software engineering approaches in 
order to ensure effective deployment and to enable reuse. 

The papers selected for this book represent advances in software engineering 
approaches to the development of realistic multi-agent systems. Research pre- 
sented in this volume illustrates a broad range of techniques and methods that 
are being used to cope with the complexity of systems like these and to facilitate 
the construction of high-quality MASs. Furthermore, the power of agent-based 
software engineering is demonstrated through examples that are representative 
of real-world applications. These papers describe experience and techniques as- 
sociated with large MASs in a variety of problem domains. 

Given the comprehensive selection of case studies and software engineering 
solutions for MAS applications, this book provides a valuable resource for a vast 
audience of readers. The intended primary audience for this book includes re- 
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searchers and practitioners who want to keep up with the progress of software 
engineering for MASs, individuals keen to understand the interplay between 
agents and objects in software development, and those interested in experimen- 
tal results from MAS applications. Software engineers involved with particular 
aspects of MASs as part of their work may find it interesting to learn about using 
software engineering approaches in building real systems. A number of chapters 
in the book discuss the development of MASs from requirements and architec- 
ture specifications to implementation. One key contribution of this volume is the 
description of the latest approaches to reasoning about complex MASs. 

This book brings together a collection of 16 papers addressing a wide range 
of issues in software engineering for MASs, reflecting the importance of agent 
properties in today’s software systems. The papers presented describe recent 
developments in specific issues and practical experience. The research issues ad- 
dressed consist of: (i) integration of agent abstractions with other software engi- 
neering abstractions and techniques (such as objects, roles, components, aspects, 
and patterns); (ii) specification and modelling approaches; (iii) innovative ap- 
proaches for security and robustness; (iv) MAS frameworks; and (v) approaches 
to ensuring quality attributes for large-scale MASs, such as dependability, scala- 
bility, reusability, maintainability, and adaptability. At the end of each chapter, 
the reader will find a list of interesting references for further reading. The book is 
organized into five parts, which deal with topics related to: (i) requirements engi- 
neering, (ii) software architecture and design, (iii) modelling, (iv) dependability, 
and (v) MAS frameworks. 

This book is a natural continuation of a previous one 1 . The main motiva- 
tion for producing this book was the 2nd International Workshop on Software 
Engineering for Large-Scale Multi-agent Systems (SELMAS 2003) 2 , organized 
in association with the 25tlr International Conference on Software Engineering, 
held in Portland, Oregon, USA, in May 2003. SELMAS 2003 was our attempt to 
bring together software engineering practitioners and researchers to discuss the 
multifaceted issues arising when MASs are used to engineer complex systems. It 
was later decided to extend the workshop scope: inviting several workshop par- 
ticipants to write chapters for this book based on their original position papers, 
and inviting other leading researchers in the area to prepare additional chapters. 
Following an extensive reviewing process involving more than 80 reviewers, we 
selected the papers that appear in this volume. 

We are confident that this book will be of considerable use to the software 
engineering community by providing many original and distinct views on such an 
important interdisciplinary topic, and by contributing to a better understanding 
and crossfertilization among individuals in this research area. It is only natu- 



1 Garcia, A., Lucena, C., Castro, J., Zambonelli, F., Omicini, A. (editors): Software 
Engineering for Large-Scale Multi-agent Systems. Lecture Notes in Computer Sci- 
ence, vol. 2603, Springer- Verlag, April 2003. 

2 Garcia, A. el al.: Software Engineering for Large-Scale Multi-agent Systems - SEL- 
MAS 2003 (Workshop Report). ACM Software Engineering Notes, Vol. 28, No. 6, 
November 2003. 
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ral that the choice of contributors to this book reflects the personal views of the 
book editors. We believe that, despite the volume of papers and work on software 
engineering for MASs, there are still many interesting challenges to be explored. 
The contributions that can be found in this book are only the beginning. Our 
thanks go to all our authors, whose work made this book possible. Many of them 
also helped during the reviewing process. We would like to express our gratitude 
to Juris Hartmanis, and Alfred Hofmann of Springer- Ver lag for recognizing the 
importance of publishing this book. In addition, we would like to thank the 
members of the Evaluation Committee who were generous with their time and 
effort when reviewing the submitted papers. We gratefully acknowledge the sup- 
port and cooperation of Claudio Sant’Anna (LES, PUC-Rio) who helped us in 
the preparation of this volume. 
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A Framework for Complex Socio-technical Systems 
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Abstract. Adopting Requirements Engineering (RE) techniques based on the 
fundamental notions of the agent-oriented programming paradigm, i.e., Agent , 
Goal, and Intentional Dependency, has been recognized as a crucial step to- 
wards a more homogeneous and natural software engineering process for com- 
plex socio-technical systems, among which Multi Agent Systems. The availabil- 
ity of simple representational tools is a key factor to guarantee stakeholders" ac- 
tive involvement during RE, and therefore the success of the RE process itself. 
The paper introduces an agent-based Requirements Engineering Framework 
(REF), devised to deal with socio-technical systems, and support stakeholders’ 
participation. REF is designed around the adoption of a simple, but effective, 
graphical notation. Nevertheless, the simplicity of the graphical language may 
constraint the analysis process, reducing its flexibility and efficiency. This trade- 
off is carefully analysed, and some extensions are proposed, which do not affect 
REF clarity and intuitiveness, while enhancing REF capability to support require- 
ments engineers in planning and implementing their analysis strategies. 



1 Introduction 

Agent-oriented programming paradigms and Multi Agent Systems (MAS) offer the 
great advantage of adopting the concept of Agent (together with the related notions of 
Goal, Intentional Dependency, Resource, and Task) commonly used also for describ- 
ing the social setting in which the system has to operate. Thus, the possibility of using 
such notions as primitive elements for describing the system requirements during the 
Requirement Engineering (RE) process is becoming more and more relevant, especially 
for MAS application solutions. Agent- and goal-based RE approaches represent a first 
step to fill the gap between RE and Software Engineering (SE), especially, although not 
only [21], when MAS are concerned [5,4], Many SE techniques have been developed 
for MAS [18,23], but few of them try to analyze and take into account the impact of 
the final system over the encompassing organization since the early phases of the RE 
process. 

In such a perspective, the paper introduces an agent-based RE Framework (REF), 
initially applied for the definition of the requirements of a complex simulation envi- 
ronment [11], REF is strongly based on diagrammatic notations, which immediately 

C. Lucena et al. (Eds.): SELMAS 2003, LNCS 2940. pp. 1-18, 2004. 

© Springer- Verlag Berlin Heidelberg 2004 
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convey the dependencies among different actors (or agents), and allow for a detailed 
analysis of the goals, upon which the actors depend, through a goal decomposition pro- 
cess. REF actors may be social (individuals and organizations, e.g., enterprises, depart- 
ments, offices), as well as artificial (physical, as an hardware system, and software, as 
a software agent or a society of software agents inside a software system). The adopted 
graphical notation is widely inspired by the i* framework [25] for RE [24], and business 
analysis and re-engineering [26]. 

Denotationally inspired by i* REF introduces a clear process to drive requirements 
discovery, definition, refinement, and reconciliation [11], while maintaining the nota- 
tional ingredients at an essential level. This choice, apparently constraining, results in- 
stead to be quite successful in practical terms. Several case studies [13, 12, 1 1] demon- 
strate, in fact, that the simplified notation facilitates the acceptance of the diagrammatic 
language by the stakeholders, and contributes to a quicker introduction of REF in the 
RE process. Nevertheless, such simplifications may still be consider as possible limits 
to the REF expressive power and, consequently, to the intentional analyses that could 
otherwise be carried out. 

In this paper, after a brief introduction to REF (Section 2), an extensive and con- 
crete case study is adopted to critically revise the analysis process underlying the cur- 
rent framework, and propose two notational and methodological extensions as solutions 
(Section 3). In Section 4, we suggest that, when appropriately used, the proposed ex- 
tensions do not jeopardize REF usability and its acceptance by the stakeholders, but 
support the analysts in planning and performing a more efficient analysis strategy. 



2 Introduction to REF 

REF is designed to deal with, and reason about, socio-technical systems. Here the soft- 
ware system and its application context form a larger human and technological system 
that has to be treated and analyzed as a whole, and the overall needs are the ones to be 
fulfilled [15, 18, 23]. Complexity of socio-technical systems goes beyond working pro- 
cedures and the complexity of the software system itself: it encompasses the complexity 
generated by the impact of the system upon the organizational structure, from the busi- 
ness process, to the behavior of the single employee. The basic idea behind REF is to 
provide the analyst with the right tools to capture the high-level organizational needs 
and transform them into organizational and system requirements. Application context 
has in fact often to be adapted in order to exploit the capabilities of the new system. The 
framework tackles the modeling effort by breaking the activity down into more intellec- 
tually manageable components, and by adopting a combination of different approaches, 
on the basis of a common conceptual notation. 

Agents are used to model the organization [9, 11, 19,24]. The organizational con- 
text is modeled as a network of interacting agents, collaborating or conflicting in order 
to achieve both individual and organizational goals. Goals [22, 1, 8, 1 1, 24] are used to 
model agents’ relationships, and, eventually, to link organizational needs to system re- 
quirements. According to the nature of a goal, a distinction is made between hard goals 
and soft goals. A goal is classified as hard when its achievement criterion is sharply 
defined. For example the goal “ document be available ” is a hard goal, being easy to 
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check whether or not it has been achieved (i.e., is the document available, or not?). For 
a soft goal, instead, it is up to the goal originator, or to an agreement between the in- 
volved agents, to decide when to consider the goal as achieved. For example, the goal 
“ document easily and promptly available” is a soft goal, given that as soon as we in- 
troduce concepts such as “easy” and “prompt”, different persons usually have different 
opinions. 

Distinguishing goal modeling from organizational modeling, and then further dis- 
tinguishing between hard goal modeling and soft goal modeling, is a key aspect of 
REF, and helps reducing the complexity of the modeling effort. The proposed frame- 
work, therefore, supports three inter-related modeling efforts [3]: the Organizational 
Modeling , the Hard Goal Modeling and the Soft Goal Modeling. 

During Organization Modeling , the organizational context is analyzed and the 
agents and their goals identified. Any agent may generate its own goals, may oper- 
ate to achieve goals on the behalf of some other agents, may decide to collaborate with 
or delegate to other agents for a specific goal, and might clash on some other ones. The 
resulting goals will then be refined, through interaction with the involved agents, by 
hard and soft goal modeling. 

The Hard Goal Modeling seeks to determine how an agent thinks to achieve a hard 
goal, by decomposing it into more elementary subordinate hard goals and tasks (where 
a task is a well-specified prescriptive activity). 

The Soft Goal Modeling seeks to determine how an agent thinks to achieve a soft 
goal, by decomposing it into more elementary subordinate soft goals, hard goals, tasks, 
resources [24,7], and constraints [11, 14]. Soft goal modeling aims at producing the 
operational definitions of the soft goals, thus soft goals refinement has to be reiterated 
until only hard goals, tasks, resources and constraints are obtained (that is, until all the 
“soft” aspects are dealt with). 

Both soft and hard goals are refined by repetitively asking the agents what they 
needed to know, to perform, have delivered or have performed (and by whom, lead- 
ing in this way to the identification of new agents), in order to consider the goal as 
achieved. For soft goal modeling, in addition, REF provides the constraints as mecha- 
nisms to harden softness. So, for example, the soft goal “ document easily and promptly 
available ”, besides spawning the hard goal “ document available”, will lead also to a set 
of constraints (e.g., types of access channels, number of hours after which a document 
is available, etc.), specifying the concepts of easy and prompt. 

2.1 The Case Study: ERMS 

In order to introduce REF, paving at the same time the way for discussing its limits and 
possible extensions (Section 3), we describe an on-going project aiming at introduc- 
ing an Electronic Record Management System (ERMS) into a complex administrative 
organization. The system is expected to affect a large community of knowledge work- 
ers. Indeed, ERMS is at the moment used by more than 300 employees and handles a 
flow of about 200.000 documents/year, but it is designed to reach about 2000 users and 
2 million documents/year. 

An ERMS is a complex Information and Communication Technology (ICT) system 
that allows efficient storage and retrieval of document-based unstructured information, 
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Fig. 1 . Introducing the ERMS: the initial model 



by combining classical filing strategies (e.g., classification of documents on a multi- 
level directory, cross-reference between documents, etc.) with modern information re- 
trieval techniques. It usually provides mechanisms for facilitating routing and notifica- 
tion of information/document among the users, and interacting with similar (typically 
remote) systems, through e-mail and XML. An ERMS represents the basic element for 
a knowledge workplace, i.e., a working environment where a knowledge worker can 
easily access and gather information, produce knowledge and deliver results through 
a multitude of channels (from personal computers, to laptops, PDAs, mobile phones, 
etc.). It is, in fact, a necessary step for introducing more sophisticated document man- 
agement tools, such as workflow technology and digital signature, both fundamental 
mechanisms for a paperless and ubiquitous working environment. Several factors (inter- 
national benchmarking studies, citizens demand, shrink budgets, etc.) lead to the deci- 
sion of leveraging new technologies to transform the organization bureaucratic structure 
into a more creative, and knowledgeable environment. 



Starting the Analysis. The initial organization model expressing the situation intro- 
duced above is shown in Figure 1 . Circles represent Agents, and dotted lines are used to 
bound the internal structure of complex agents; that is, agents containing other agents. 
Thus, in Figure 1, the agent Organization Unit is a complex agent, representing the orga- 
nizational structure into which the ERMS has to be introduced; the Head of Unit is the 
agent acting within the Organizational Unit who is in charge for achieving the improve- 
ment objectives (modeled by the soft goals exploit ICT to increase performance while 
avoiding risks, and cost/effective and quick solution). Goals, tasks and agents (see also 
next figures) are connected by dependency-links, represented by arrowhead lines. An 
agent is linked to a goal when it needs or wants that goal to be achieved; a goal is linked 
to an agent when it depends on that agent to be achieved. Similarly, an agent is linked 
to a task when it wants the task to be performed; a task is linked to an agent when the 
agent is committed at performing the task. Again, an agent is linked to a resource when 
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it needs that resource; a resource is linked to an agent when the agent has to provide 
it. By combining dependency-links, we can establish dependencies among two or more 
agents. 

At this point, to continue with the analysis, the goals resulting from the initial model 
have to be refined by means of goal modeling. In the following we focus on the soft goal 
exploit ICT to increase performance while avoiding risks. 

Goal Modeling. Figure 2 describes how the soft goal exploit ICT to increase perfor- 
mance while avoiding risks is iteratively top-down decomposed to produce a set of tasks, 
hard goals, and constraints that precisely define it. Figure 2, in other terms, represents 
the strategy that the Head of Unit (as the result of a personal choice or of a negotiation 
with the upper organizational level) will apply to achieve the assigned goal. Again, the 
arrowhead lines indicate dependency links: a goal depends on a sub-ordinate goal, task 
or constraint, when it requires that goal, task or constraint to be achieved, performed, or 
implemented in order to be achieved itself. Goals decompositions may be conjunctive 
(all the sub-components must be satisfied, to satisfy the original soft goal), indicated by 
the label “A” on the dependency link, or disjunctive (it is sufficient that only one of the 
components is satisfied), indicated by the label “O” on the dependency link (see Fig- 
ure 4). According to Figure 2, the Head of Unit has to increase personal performance, 
to increase productivity of the whole unit, and also to avoid risks due to new technology. 
Let us consider in details only the first sub - soft goal, i.e., increase personal perfor- 
mance. It spawns two subordinate soft goals, easy document access, for which the 
Head of Unit will require a multi-channel access system in order to be able to check and 
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transfer the documents to the employees also when away from the office (asking at the 
same time that secretary does not filter the documents), and increase process visibility, 
to take better informed decisions. In particular, the soft goal increase process visibility 
will eventually lead to the identification of some tasks (functionalities) that the system 
will have to implement to provide some data about the process (number of documents 
waiting) and about the employees (provide employee’s number of documents), together 
with some associated constraints, represented by a rounded-rectangle with a horizontal 
line. In Figure 2, for example, they specify the frequency of update: daily update for the 
process data and weekly update for the employee’s ones. Finally, in Figure 2, the items 
in bold outline are those that the Head of Unit will pass out, having decided to depend 
on other agents for their achievement. For such a reason, they are not further analyzed; 
instead they will be refined as further agreement between the Head of Unit and the agent 
that will be appointed of their achievements. 



Extending the Organizational Model. The results of the goal analysis allow us to 
enrich the initial organization model in Figure 1, leading to the model in Figure 3. Here 
- where some details have been omitted for the sake of clarity - some new agents have 
been introduced: the Archivist and the Employee, which have to be more productive, 
the IT (i.e., the Information Technology Unit), which has to guarantee security, and the 
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Fig. 4. The be more productive Soft Goal Model 



ERMS. From Figure 3, we can also see that the Head of Unit has decided to delegate the 
soft goal cost/effective and quick solution to the IT agent, which, on its turn, will have to 
achieve other goals coming from the external environment, such as, for example, apply 
public administration standards. Again, at this point, the analysis can procede through 
goal modeling. Below, we focus on how the Employee will try to achieve the soft goal 
be more productive. 



More Goal Analysis. In Figure 4 we can see how, in order to be more productive, the 
Employee will require a system easy to learn, and facilitating the collaboration with 
other employees easier (soft goal make collaboration easier). 

The soft goal easy to learn will spawn, among other items here omitted, the con- 
straint adopt known technologies (i.e., technologies which the employee is already used 
to), whereas the soft goal make collaboration easier will lead, through further refine- 
ment, to a serie of hard goals implying specific capabilities (e.g., either a teleconference 
or an IP-based collaboration tool) and access channels (e.g., mobile phone, laptop, etc.). 

As already seen for the IT agent, also the Employee may have his/her own needs, 
leading to new goals. For example, the Employee may be concerned of possible side 
effects on the privacy related to the introduction of the ERMS, represented by the soft 
goal protect my privacy upon the ERMS, introduced in Figure 3. By modeling the soft 
goal protect my privacy (Figure 5), we can discover that the Employee wants to be sure 
that its own private area of work will not be accessible by others, asking for example to 
be enabled to adopt a cryptography tool (whit a 128 bit length security key) to protect 
particular data, but above all, given that all the activities will be performed through 
the ERMS, that s/he does not want someone to be able to monitor his/her actions. This 
clearly conflicts with the possibility of monitoring the employee’s performance that was 
required by the Head of Unit (Figure 2), requiring some trade-off to be identified. 
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Fig. 5. The protect my privacy Soft Goal Model 



2.2 REF Background 

In the last years, domain modeling has been recognized in RE as crucial for a suc- 
cessful system development: this includes activities aiming at understanding why the 
system is needed, how it would meet such goals, and possible alternatives, while taking 
into account the interests and the perspectives of all the different stakeholders [1,4, 10, 

22.24] , REF builds on such results by combining advanced requirements engineering 
techniques (i.e., agents [9, 11,24] and goals [1,8, 11, 19,22,24]) with software qual- 
ity modeling approaches [2,6, 17], to capture the stakeholders’ perception of quality 
since the beginning of a new project, and to produce agreeable-upon and implementable 
functionalities and constraints. 

REF is strongly based upon /*, the modeling framework suggested by Eric Yu [26, 

25.24] , However, it introduces some simplifications and adopts a more pragmatic ap- 
proach in order to obtain a greater and more active involvement of the stakeholders 
during the requirements discovery, elicitation and formalization process. The aim is to 
let the stakeholders to easily grasp the notation since the beginning of a project. Thus, 
the adopted simplifications include: 1) the use of only one type of actor/agent (i.e., 
no distinction is made between agent, role and position ); 2) the use of only one kind 
of link, both as dependency link as well as decomposition and means-end link. This 
choices allows for a more intuitive reading of the REF diagrams, introduces the pos- 
sibility of easily modeling many-to-one and/or one-to-many agent-goal relationships 
very common in real situations, as well as a more natural representation of the flow of 
dependencies, from the dependencies among actors, in the organization model, to the 
decomposition dependencies, in the (hard and soft) goal models. 

For what concerns the application process, REF adopts a strict top-down approach, 
during which the analysts, in close cooperation with the stakeholders, drill through the 
organization, until reaching the desired level of detail, by using three different (but sim- 
ilar) modeling tools: organization models, soft goal models, and hard goal models. In 
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particular, once an initial model of the organization is built, the REF process evolves in 
a cyclic way through two main phases: a) goal modeling phase, during which the soft 
and hard goals discovered during organization modeling are refined; and b) organiza- 
tion modeling phase, during which the analysts use the information gained modeling 
the goals to enrich and extend the initial organizational model: i.e., to replace the goals 
with their models, and to introduce the new agents identified as relevant to achieve those 
goals. New agents are therefore identified, and brought into the picture, depending on 
the specific goals to achieve, and the indications of the other agents. New agents usu- 
ally lead to new goals, triggering the goal-modeling phase again [3]. Such a cycle is 
continued until the desired (and needed) level of details is reached. Unlike i* (and also 
NFR [7] and Tropos [20,4], that share with i*the notion of soft goal satisfcement [24]), 
REF emphasizes the operational role that soft goals can play in deriving the require- 
ments of a new system. Soft goals, in fact, beyond being crucial in supporting reasoning 
between alternatives (as in i* NFR and Tropos), since the early stages of a project, can 
also provide a systematic and organized way of handling non-functional requirements. 
In particular, REF recognizes the need of explicitly “resolving” soft goals, by turning 
them into more manageable (and implementable) hard goals, tasks and constraints. This 
last notion - constraint - is not, indeed, present in i*, NFR, nor Tropos. 

To refine a soft goal, the analysts have first to specify the actions that are usually 
implied, and sometimes hidden in the goal (e.g., to make a document available in the 
soft goal document easily and promptly available), then they have to make operational 
its softness (e.g., in identifying the constraints that describe the concepts of easily and 
promptly). By repetitively asking the agents what they need to achieve, to perform, or 
have delivered in order to consider the soft goal as achieved, it is possible to slowly 
separate the actions implicit in the goal (represented by the emerging hard goals, tasks, 
and resources), from its softness (represented by the emerging and more elementary soft 
goals). Eventually, the emerging soft goals will be “pure” soft goals, specifying quality 
attributes of the identified actions. To further refine these pure soft goals, REF borrows 
ideas from quality modelling and measurement definition techniques. In refining such 
a softness, i.e., to make it operational, in fact, the analysts perform a two-step process: 
1) First, they build a quality model [6] of the soft (quality) attribute, by identifying the 
characteristics that the stakeholders assume to be important in judging it. For example, 
for assessing how easily and promptly a document is available, we can identify, as rel- 
evant, system characteristics such as the types of access channels, the number of hours 
after which the document is available, the possibility of mobile access, and so on. 2) 
Second, they populate the quality model and freeze the result, by specifying for each 
characteristic the desired values (or range of values), according to the corresponding 
measurement scale [14]. So, for example, for the limit of hours after which the docu- 
ment has to be available (absolute scale), a number or a range of numbers have to be 
assigned, while, for the types of access channels (nominal scale), the desired values 
have to be specified (e.g., mobile phone, laptop, etc). 

To define the quality model of the soft attribute, the analysts may turn to quality 
models already available in literature [14], such as the McCall, the Bohem, or the IEEE 
standard, or adopt more sophisticated empirical measurement identification methods, 
such as the Goal Question Metric (GQM) approach proposed by Basili [2] and its ex- 
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tensions [6]. Quality models show little flexibility and may result difficult to customize 
to the specific contexts and agents’ needs. On the contrary, empirical measurement iden- 
tification methods recognize that quality issues cannot live in isolation, but have to be 
derived from, and linked to, their operational context (i.e., stakeholders, problem do- 
main, underlying reasons, etc.). 

The most classical of the empirical methods is the GQM approach, based on the 
idea that measures have to be identified starting out from the analysis of the goal that 
has to be achieved. The goal (precisely stated, by specifying the object of study, the pur- 
pose, the quality focus, the viewpoint and the context) is refined into several questions 
that break down the issue into its major components, and each question is refined into 
metrics. Basically, measures are obtained by applying a question-answer mechanism: 
ask which "Questions” we should be able to answer in order to achieve the “Goal”, and 
then ask what "Metrics” we should collect to be able to answer those questions. In such 
a perspective, a GQM-like approach has been applied for goal refinement during soft 
goal modeling. For each soft goal, in fact, REF clearly identifies the target object (ob- 
ject of study), the reasons (purpose), the soft attribute (quality focus), the stakeholder 
(viewpoint), and the application context (context), providing the basis upon which a 
GQM-like question-answering mechanism can be adopted as technique to support elic- 
itation. In other terms, to support the identification and to populate the quality model, 
i.e., the set of constraints (metrics) that complete the goal refinement. Constraints do 
not leave in isolation, but assume meaning only when associated to the hard goal, task, 
or resource that they specify. 



3 Improving REF Analysis Capability 

As described in Section 2, REF aims at providing a representational framework for 
requirements discovery, definition and analysis characterized by a graphical notation 
sufficiently expressive to deal with complex problems but, at the same time, simple 
enough to be easily and quickly grasped by the stakeholders, usually unfamiliar with 
RE techniques. These are quite relevant aspects which make REF suitable for real ap- 
plications [13, 12, 11], and ensure an active stakeholders’ involvement, critical for a 
quicker and more effective knowledge acquisition and requirements elicitation process 
capable of leading to domain descriptions close to the real state of affairs [22, 11]. 

We believe REF simplicity is mainly due to two key features, characterizing its goal 
modeling activities: 1) a very sparse notation, and in particular the use of only one type 
of link (the dependency link); 2) the focus, during goal analysis, on only one goal and 
one agent at time. This leads to simple tree-like goal diagrams, generated by a strict 
top-down process, and independent from the way in which they are developed. In other 
terms, while both these REF aspects lead to easily readable diagrams, the second one, in 
particular, allows the analysts and the stakeholders to focus on only one problem at the 
time, without need to worry about the order in which the analysis of different sub-trees 
is carried out: the resulting diagram is always generate in the same shape, whichever 
node expansion sequence is followed (breath first, depth-first, o mixed). 

Although important for REF simplicity, such features may however constraint the 
analysis process, limiting its flexibility and efficiency. Tree-like diagrams, in fact, de- 
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veloped by focusing on one agent and one goal at the time, may oversimplify real case 
situations and reduce the possibility for the analysts of efficiently dealing with situa- 
tions in which parts of the diagram (sub-goals or constraints, or tasks, or resources) 
could be in common or in conflict within the diagram itself or between different ones. 
In other terms, they hinder the analysts’ capabilities of identifying, reasoning about, 
and respectively, resolving or exploiting sharing and conflicts situations. As discussed 
in [11], dealing with tree only requires to perform most of the analysis before being 
able to detect conflict or sharing situations, and then re-do part of the effort. 

In the following, we highlight and discuss concrete examples where such limits ap- 
pear to be evident, and suggest extensions of REF, in order to introduce more flexibility 
in the process of model description and requirements elicitation, without affecting its 
initial simplicity. 



3.1 Sharing Goals (Tasks, Constraints, . . . ) 

Top-down tree expansion and analysis induces to introduce different sub-goals (or con- 
straints, or tasks, or resources) for any different goal that is found during the goal anal- 
ysis activity, even when different goals could be (partly) satisfied by the same sub-goal 
(or constraint, or task, or resource). This situation may be further distinguished in at 
least three different sub-cases. 



First Case: Commonalities within the Same Goal Diagram. In Figure 2, for exam- 
ple, two distinct constraints have been introduced for satisfying the soft goals provide 
process performance and provide employee’s performance, namely the constraints daily 
update and weekly update, also if the Head of Unit could have accepted them to share 
the same constraint (e.g., a twice a week update, as in Figure 6). According to REF, 
in fact, any sequence may have been followed in analyzing the two soft goals, and the 
two constraints may have been introduced in two very different moments, making it 
very difficult to spot that a common (although slightly different) constraint could have 
been adopted. This tradeoff, on the other side, could have been identified and judged 
as acceptable if considered by the analyst together with the Head of Unit at the proper 
moment during the elicitation activity. 

While the difference between Figures 2 and 6 is minimal, regarding only leaf nodes 
(as highlighted by the dotted circle), let us consider a more complex hypothetical case, 
in which the two collapsing nodes are non-leaf nodes, but have deep trees expanding 
from them. 

In this case, relevant parts of the two sub trees, rooted in the two nodes, would 
have to be revised, in order to consider an alternative non-tree-based analysis. It results 
therefore to be strategic to be able to introduce a common child for the two nodes be- 
fore proceeding with the analysis of the nodes sub-trees. It is clear in fact how different 
diagram evolution strategies, and thus development sequences, could lead to quite dif- 
ferent results or, eventually, to the same result but with a different degree of efficiency 
(depending on the strategy). For example, a top-down breath-first diagram expansion 
could be preferred to a top-down depth-first one. In this way, it may appear appropriate 
to develop a shared sub-tree only once, with two advantages: 1) at the elicitation level, 
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Fig. 6. The exploit ICT ... Soft Goal Model revised 



the analysis does not have to be carried out twice; 2) at the implementation level, the 
complexity of the system will be reduced, being two potentially different requirements, 
and all the following details, collapsed in one. Of course, not always merging two nodes 
(and eventually all their sub-trees) is a reasonable choice, and has to be the result of a 
compromise that needs to be carefully evaluated. It is up to the analyst (together with 
the stakeholders) to decide if such an option is acceptable. The important fact here is 
that, allowing the analysts to show the possible set of shared requirements (easily and 
visually appraisable) allows also to reason about the amount of savings in elicitation and 
implementation time. In other terms, the analysts have a more powerful tool to evaluate 
alternatives, also taking into account the possible consequences in terms of system de- 
sign and development efforts. Considerable advantages seems to be introduced by the 
possibility of considering also directed a-cyclic graphs, instead of only trees, as design 
artefacts. 

Indeed, a risk is present, and has to be carefully considered: the strict REF approach 
is much more simple, and make the tree expansion order irrelevant, so improving us- 
ability and comprehension of the process; to find, instead, possible common sub-goals, 
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continuous (or at least very frequent) comparison of sub-goals is necessary, and the 
expansion sequence may make some difference: this constraint make the process users 
(that are, the analysts, but specially the stakeholders) more bound to rules and intuition 
on the best path. 

Second Case: Commonalities within Different Goals Diagrams of the Same Actors. 

This is a specialization of the first case, where similar sub-goal sharing happens among 
goals placed upon an actor during the organizational model analysis. In this case, the 
REF methodology would lead the analyst and the stakeholder to duplicate the sub-goal 
in two different diagrams, usually with slightly different labels, although with the same 
semantics. Again, catching these cases would avoid duplicated efforts. 

Moreover, as soon as a sub-goal is recognized as shared by different goal diagrams, 
immediately it becomes more relevant than other ones, being its satisfaction useful (or 
necessary or sufficient, or both) to two goals. Thus, the decision could be made that 
more elicitation, analysis and implementation efforts should be applied to this particu- 
larly valuable sub-goal. 

Third Case: Commonalities within Different Goals Diagrams of Different Actors. 

This is a more intriguing situation, where the same sub-goal is shared between two 
different actors, as a consequence of the independent analysis carried out by the two 
agents on two different goals placed upon them. 

Consider for example the increase personal performance soft goal in Figure 2, from 
which the soft goals easy document access and increase process visibility are derived. 
The first one, on its turn, leads to the soft goal multi-channel access. The same soft 
goal multi-channel access is present also in Figure 4, as result of the analysis of the 
soft goal be more productive for the Employee, that is as a soft goal that the employee 
considers as relevant in order to become more productive. Again, as in the previous 
cases, the analysis of such a shared soft goal immediately assume a higher relevance and 
priority over the analysis of other ones. Two actors desire its satisfaction! The analysis 
can therefore be carried out once for both the actors, exploiting the approach to better 
combine their needs in a synergic way, and avoiding duplications that, although most 
of the times are due only to slightly different ideas, may generate over complexity in 
terms of systems functionalities. For example, leading to the selection of only one kind 
of mobile access channel able to satisfy both the agents. 

From the analysis of all the previous three cases, clearly emerge the need of in- 
troducing in REF some mechanism to support the analysts during goal modeling. In 
particular, we propose to provide the analysts with a specific notation to be used to 
highlight situations where they believe that some commonalities could be hidden, i.e., 
that shared-goals could arise during the analysis. In other terms, to introduce in REF a 
notation suitable to act as a high-level reasoning support tool to enable the analysts to 
record their intuitions while building the goals models: i.e., making notes to drive their 
strategies. For example, to highlight where a top-down bread-first diagram expansion 
may be preferable to a top-down depth-first strategy. As such a notation, we introduce 
a dotted labeled line to connect the two or more goals among which a possible sharing 
could emerge. The line (the S-connection ) does not have arrows, being the relationship 
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Fig. 8. Sharing between goals of different agents 



perfectly symmetric, and it is marked by the label S, that stands for Sharing. Figure 7 
shows a fragment of Figure 2 where the S-connection has been adopted. In particular, 
it shows how the S connection could have been used during the analysis of the soft 
goal to highlight in advance the possibility of sharing between the soft goals provide 
employees performance and provide process performance (the first example case pre- 
viously analyzed). In the same way, in Figure 8 is depicted the use of the S-notation to 
highlight, within the soft goal analyzed in Figure 2, a possible sharing between the soft 
goal increase personal performance, that the Head of Unit wants to achieve, and the soft 
goal be more productive, that the Head of Unit imposes, transfers to, the Employee (the 
third example case previously analyzed). 

It is worth noting how the S-notation is only a reasoning support mechanism that 
tends to disappear once the analysis proceeds. In other terms, the S-notations purpose is 
to mark possible sharing situations to drive the analysis (e.g., bread-first, multi-agents 
analysis, repeated back to back comparisons, and so on), but does not have any reason 
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to exist any more once the goals have been explored: the initial REF notation, with its 
simplicity, is sufficient for that regard. 

3.2 Clashing Goals (Tasks, Constraints) 

Up to here we have been concerned with the possibility of sharing (among different 
actors, or among goals of one actor) one or more sub-goals (or constraints, tasks, and 
resources). Another interesting, and actually very common situation, regards the possi- 
bility of efficiently dealing with clashing needs (goals, constraints, tasks, or resources). 
Of course, as far as a strictly top-down analysis is performed (as currently done in REF), 
there is no explicit reason to introduce contrasting elements in the design. 

But they may arise as soon as considering the situations discussed above. As well 
as during a top-down analysis an introduced sub-goal may be recognized as helpful for 
another one (possibly of another actor), in a similar process it may result (possibly) 
harmful. In addition, during the analysis, new agents may have to be introduced into the 
context (e.g., the Head of Unit requires the Employee to be more productive), and such 
new agents may express their own needs by introducing new goals in the context. Such 
goals may very easily clash with other goals already in the context. 

A clear example is represented by the soft goal protect my work performance in 
Figure 5, leading to the constraint that the ERMS should not be allowed to monitor and 
record data regarding the Employee actions. This clashes with the desired expressed by 
the Head of Unit of knowing the number of documents each Employee is dealing with 
(Figure 2). Indeed, as just seen in the discussed example, REF already supports the 
recognition of such situations. When fully operationalised in terms of tasks and con- 
straints, goals models in fact can be adopted to detect clashing situations and to resolve 
them. In this case, for example, the decision could be made of providing the Head of 
Unit only the average of the documents dealt with by all the Employees, so protecting 
the privacy of the single one. Nevertheless, we think it may be very useful to be able 
to recognize such situations as early as possible, also at a very qualitative level, before 
than pushing the analysis down to the final constraints and details. For such a reason, 
to enable the analysts to mark possible conflicting situations (and build their refinement 
strategy to deal with them), we introduce the H-connection, FI for Hurting. This is a 
powerful tool to detect possible conflicts and try to reconcile different stakeholders’ 
points of view, evolving the analyses only along the most promising alternatives. 

An example application is shown in Figure 9, where the H-notation has been used 
to highlight the possibility of a conflict between two goals before proceeding in their 
analysis (i.e., the soft goal provide employees performance is not broken down into 
tasks before taking into account the protect my privacy one). 



4 Conclusions 

The paper introduced an agent-based Requirements Engineering Framework (REF), ex- 
plicitly designed to support the analysts in reasoning about socio-technical systems, and 
transform high-level organizational needs into system requirements, while redesigning 
the organizational structure itself. The underlying concepts and the adopted notations 
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make of REF a very effective and usable tool, able to tackle complex real case situa- 
tions, while remaining simple enough to allow an active stakeholders’ involvement. 

However, we felt that REF could be improved to better support the analysts in 
dealing with complex system/organizational design issues, such as shared and clashing 
stakeholders’ needs. In both cases, an early detection of the problem can, in fact, lead to 
better analysis results: shared needs could be objects of a more intensive analysis effort 
to exploit commonalities to reduce complexity and increase reusability; clashing needs 
could be solved at a very early stage, to focus then the analysis only towards the most 
promising alternatives. Two graphical notations (i.e., S-connection and H-connection) 
have thus been introduced to allow the analysts to mark such situations and better rea- 
son about how to build their strategy. They are pure analyst-oriented tools that do not 
affect REF usability in terms of stakeholders’ perspective. We expect that their use can 
greatly improve the analysts’ capabilities of building the strategy to deal with shared 
and clashing interests, by allowing them to easily connect items (goals, constraints, 
tasks and resources) across different models and diagrams, to support their reasoning 
about the problems and about how to face them (e.g., whether or not perform a multi- 
agent elicitation session). At the same time, the S-connections and H-connections do 
not have to appear while interacting with the stakeholders, so that, once the analysis 
is completed, only the REF original notation is sufficient. Thus, S-connections and H- 
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connections have mainly to be considered as a tool for the elicitation process, and not 
as a support to alternatives evaluation, unlike what offered by other formalisms, as, e.g., 
NFR [7], 

Finally, although REF addresses only the early stages of the RE process, the possi- 
bility of combining its outcome with techniques more suitable for dealing with further 
system development phases has been investigated. For example, practical results sug- 
gest that it can be usefully applied as a forerunner to both object-oriented approaches, 
such as those based upon UML [10], as well as agent-oriented approaches for MAS 
systems [5, 16, 20]. 
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Abstract. In order to secure interoperability and allow autonomous agent inter- 
action, software for the web will be required to provide machine processable 
ontologies. Traditional deliverables of the software development process are the 
code, technical documentation, to support development and maintenance and 
use documentation, to provide user support. In the case of web applications, on- 
tologies will also be part of the deliverables. Ontologies will allow machines to 
process and integrate Web resources intelligently, enable quick and accurate 
web search, and facilitate communication between a multitude of heterogeneous 
web-accessible agents [1], We understand that the responsibility, not only for 
making explicit this requirement, but also to implement the ontology, belongs to 
software engineers. Currently the development of ontologies is more of a craft 
then a systematic discipline. We are proposing a process for the systematic con- 
struction of ontologies, centered on the concept of application languages. This 
concept is rooted on a representation scheme called the language extended lexi- 
con (LEL). We demonstrate our approach using an example in which we im- 
plement a machine processable ontology for a meeting scheduler using the on- 
tology language DAML+OIL. 



1 Introduction 

Researchers from industry and academia are exploring the possibility of creating a 
"Semantic Web," in which meaning is made explicit, allowing machines to process 
and integrate Web resources intelligently. This technology will allow interoperability 
among development of intelligent internet agents in large scale, facilitating commu- 
nication between a multitude of heterogeneous web-accessible devices. Unfortu- 
nately, the majority of the information available is in a format understandable to hu- 
mans alone, making the automation of search and retrieval processes very hard [1], 
Ontologies should provide the necessary meaning to web content therefore enabling 
software agents to understand and retrieve information in relevant contexts f 14]. 

The development of ontologies today is more of a craft than a science [10]. Avail- 
able processes for ontology building provide little support to basic knowledge acquisi- 
tion activities, such as elicitation and modeling , and focus on formalization aspects 
[15,31,9,13,29]. The final result is that the ontology construction process becomes 
time consuming and onerous. 
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From an agent perspective, an ontology is a software deliverable. It has to be made 
available in order to allow interoperability among a large community of agents that, in 
turn, interact with other ontologies. Agent developers need ontologies to test their 
agent behavior and to promote large scale interoperability. We propose an ontology 
construction process rooted on a representation scheme called the language extended 
lexicon (LEL) [23]. A lexicon term is composed of notion (denotation) and behavioral 
responses (connotation). The list of behavioral responses makes the LEL special, in 
relation to other lexicons or dictionaries, because it provides additional information to 
the meaning of terms in the format of a list of relationships to other lexicon terms. 
The particular structure of the LEL makes it an excellent basis for ontology construc- 
tion. 

The proposed process is systematic enough as to allow people who are not experts 
in knowledge engineering to perform it. We demonstrate our proposal using an exam- 
ple in which we implement a machine processable ontology for a meeting scheduler 
in the DAML+OIL ontology language. 



2 Ontologies 

We adopt the ontology structure O proposed by Maedche [26] . According to the au- 
thor, an ontology can be described by a 5-tuple consisting of the core elements of an 
ontology, i.e., concepts, relations, hierarchy, a function that relates concepts non- 
taxonomically and a set of axioms. The elements are defined as follows: 

O : = {C,%! 0-f, rd, A 0 } consisting of : 

• Two disjoint sets, ('(concepts) and (^(relations) 

• A concept hierarchy, 9f: is a directed relation tfcfxf which is called con- 

cept hierarchy or taxonomy. 9f{Cj, C,) means C, is a subconcept of C 2 

• A function reC: ${.—> C x ('that relates the concepts non taxonomically 

• A set of ontology axioms _T D , expressed in appropriate logical language. 

Most existing ontology representation languages can be mapped to this structure. 
In the next section we survey some of these languages. 

2.1 Ontology Implementation Languages 

At first we considered the use of the Resource Lramework Description (RDL) [19]. 
RDL allows to express the semantics of a web page in terms of metadata. It provides 
a set of primitives for modeling simple ontologies in RDL schema, e.g., “SubClassOf ’ 
and “SubPropertyOf ’. RDL however, was criticized as an ontology language because 
it lacked expressiveness [17]. In the RDL Schema logical connectives such as nega- 
tion, disjunction and conjunction are not provided, thus restricting the expressive 
power of the ontology. 

We also considered using the Simple HTML Ontology Extension (SHOE) devel- 
oped at the University of Maryland, prior to XML and RDL [25]. SHOE is an ontol- 
ogy-based knowledge representation language that is embedded in web pages. The 
underlying philosophy of SHOE is that intelligent internet agents will be able to better 
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perform their tasks if the most useful information is provided in a structured way. 
SHOE extends HTML with a set of knowledge oriented tags and associates meaning 
to the contents of a page by making each web page commit to one or more ontologies. 
The ontologies permit the discovery of implicit knowledge through the use of tax- 
onomies and inference rules. Compared to RDF, SHOE is analogous an RDF Schema 
but with less expressive power [3], e.g., SHOE does not allow negation in the claim 
statement nor the subclass relationship for properties. Maintenance of ontologies is 
also an issue in SHOE, for they are embedded in the web pages as opposed to as sepa- 
rate objects. 

The ontology inference layer (OIL) was sponsored by the European Community 
via the on-to-knowledge project. OIL sprung from the need of an expressive language 
for creating ontologies on the web, since RDF provides inadequate expressiveness 
and lacks formal semantics and reasoning support. OIL’S formal semantics and effi- 
cient reasoning support is provided by Description Logics. The semantics of OIL rely 
on a translation into the description logic SdttCf extended with concrete data types, 
S'WQ(d) . A complete mapping of Oil to SdilQfd.) is available in [20]. The OIL com- 
munity made available tools that support editing and ontology reasoning. There are 
three editors available, OntoEdit, developed at the University of Karslruhe, OILed, 
developed at the University of Manchester and Protege-2000, developed at Stanford 
University [8]. Reasoning support for OIL is available and provided by the FaCT 
(fast classification of terminologies) inference engine, publicly available at 
http://www.cs.man.ac.uk/~horrocks/FaCT/ [20]. The reasoning services provided 
include inconsistency detection and determining subsumption relationships. OIL pro- 
vides an extension to RDF and RDFS. Based on its RDF syntax, ontologies written in 
OIL are valid RDF documents. 

The Defense Advanced Research Projects Agency (DARPA) in conjunction with 
the W3C is developing the DARPA Agent Markup Language (DAML) by extending 
RDF with more expressive constructs aimed at facilitating agent interaction on the 
web [18]. DAML released its first ontology language specification, DAML-ONT in 
October 2000. In December of the same year DAML+OIL was released to replace 
DAML-ONT. The formal semantics of DAML+OIL is provided as a mapping to first 
order predicate logic, written in ANSI Knowledge Interchange Format (KIF) [12], 
DARPA maintains an ontology library with near two hundred entries made publicly 
available at http://www.daml.org/ontologies/. The large adoption and installed base of 
daml ontologies is making it a favorite language to provide semantic interoperability 
on the web [3]. 

More recently, the W3 consortium has released the OWL (web ontology language) 
as a revision of the DAML+OIL ontology language. OWL is designed to cater the 
information processing needs of applications, as opposed to human beings. Similarly 
to DAML+OIL, OWL is intended to represent terms and their relationships in 
ontological format. OWL has three increasingly-expressive sublanguages: OWL Lite, 
OWL DL, and OWL Full. OWL Lite supports classification hierarchies and simple 
constraints, e.g., cardinality. It is intended as quick migration path from taxonomies 
and thesauri, i.e., that are free from axioms or sophisticated concept relationships. 
OWL DL supports "maximum expressiveness while retaining computational 
completeness ( all conclusions are guaranteed to be computed) and decidability (all 
computations will finish infinite time)" [27]. DAML+OIL is equivalent, in terms of 
expressiveness, to OWL DL. Finally, OWL Full supports maximum expressiveness. 
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According to the W3 consortium, it is unlikely that any reasoning sofware will be able 
to support complete reasoning for every feature of OWL Full. The documentation for 
OWL was still in the working draft stage by the time this article was written. 

Finally there is a proposal for an ontology interchange language, Ontolingua [7]. It 
was designed to support the design and specification of ontologies using a semantics 
based on KIF [12]. The set of KIF expressions that Ontolingua allows is defined in an 
ontology, called the Frame Ontology. The Frame Ontology specifies, in a declarative 
form, the representational primitives that often supported with special-purpose syntax 
and code in object centered representation systems. An Ontolingua ontology is com- 
posed of classes, relations, functions, objects distinguished and axioms. The expres- 
sive power provided by Ontolingua is unmatched by the previous languages surveyed. 
Unfortunately no reasoning support is provided until this date. 

Ontology edition and reasoning support was a key factor in our decision for 
DAML+OIL as the ontology language used. Another issue that influenced our deci- 
sion is today’s large community of DAML users and the existence of a public ontol- 
ogy library. We expect to migrate to OWL DL as soon as a more definite documenta- 
tion is made available by the W3 consortium. We are currently using the OILed tool 
for edition and the FaCT tool as an inference engine to build our ontologies. OIL'S 
formal semantics and efficient reasoning support is provided by Description Logics. 
The semantics of OIL rely on translation into the description logic SHIQ extended 
with concrete data types, SHIQ(d) . A complete mapping of Oil to SHIQ(d) is avail- 
able in [20]. OilEd generates DAML extension ontologies, using an export mecha- 
nism. 

DAML+OIL implements all ontology core elements of the O ontology structure, 
introduced in the previous section. The terminology mapping is depicted in Table 1. 
Concepts are mapped to DAML+OIL classes, relations are properties, a class hierar- 
chy is implemented using the subsumption relationship SubClassOf, and the function 
that relates concepts in a non taxonomic way are mapped to restrictions. The example 
presented in section 5 is implemented using DAML+OIL. 

Table 1. Terminology mapping between the O ontology structure and the ontology language 
DAML+OIL [2], 



| 0 Ontology Structure 


DAML+OIL 


C 


Concept 


Class 




Relation 


Property 




concept hierarchy 


Subsumption 
relationship : 
SubClassOf 


re( 


function that relates 
the concepts non 
taxonomically 


Restriction 




Axiom 


Axiom 



In the next section we present the basis of the proposed ontology development 
process, the extended lexicon of the language (LEL). 














